AI Coding 工作流
这一篇讲两件事：Vibe Coding 为什么在某些场景失效，以及替代它的 Spec-Driven Development 具体是什么。以及——这批工具到底提不提速，实测数据是怎么说的。
先说数据：感觉更快 ≠ 更快
这个领域的讨论经常停在体感上，但有几组一手研究值得先看。
METR 的随机对照试验（最有说服力的一组）
| 项 | 值 |
|---|---|
| 时间 | 2025 年 7 月，arXiv:2507.09089 |
| 设计 | 随机对照试验（RCT） |
| 样本 | 16 名资深开源开发者，246 个真实任务 |
| 代码库 | 他们平均工作过 5 年的成熟项目 |
| 工具 | Cursor Pro + Claude 3.5 / 3.7 Sonnet |
| 结果 | 用 AI 工具比不用慢 19% |
| 事前预测 | 会快 24% |
| 事后自评 | 快了 20% |
感知与现实的差距接近 40 个百分点。 多出来的开销来自写提示、等待、审查输出、以及调试 AI 引入的问题。
这个结果要怎么公平地读：样本小（16 人）、都在自己很熟悉的大型代码库里、用的是 2025 年初的工具。它不证明「AI 让所有人所有任务变慢」，它证明的是「感觉更快」不能作为「更快」的证据。
METR 的随机对照试验：预测、自评与实际测量三者方向相反。
事前预测 快 24% ██████████████████
事后自评 快 20% ███████████████
实际测量 慢 19% ██████████████ ← 方向是反的
└─ 感知与现实的差距接近 40 个百分点
多出来的开销来自写提示、等待、审查输出、以及调试 AI 引入的问题。
实验设计（决定了这组数据的适用范围）
时间 2025 年 7 月，arXiv:2507.09089
设计 随机对照试验（RCT）
样本 16 名资深开源开发者，246 个真实任务
代码库 他们平均工作过 5 年的成熟项目
工具 Cursor Pro + Claude 3.5 / 3.7 Sonnet
怎么公平地读它
样本小（16 人）、都在自己很熟悉的大型代码库里、用 2025 年初的工具
└─ 它不证明「AI 让所有人所有任务变慢」
它证明的是「感觉更快」不能作为「更快」的证据和初级 / 资深的对照
GitHub / MIT / Microsoft / Accenture 对 Copilot 的现场实验给出的画面不同：初级开发者快约 35–39%，资深开发者快 8–16%。
两组数据放在一起，可以拼出一个更有用的结论：
初级开发者受益最大。资深开发者在通用任务上受益较小，而在他们已经很熟悉的成熟代码库里，可能反而变慢。
Vibe Coding 的宣传逻辑是「AI 会填平甚至反转初级与资深的差距」。数据的方向是反的——对熟悉代码库的人在做什么的人来说，工具最多是温和的帮助，在某些任务上甚至主动拖慢。
两组研究的画面不同，合起来才是有用的结论。
GitHub / MIT / Microsoft / Accenture（Copilot 现场实验）
初级开发者 快 35–39% ██████████████████
资深开发者 快 8–16% ████████
METR（资深开发者 + 自己熟悉的成熟代码库）
资深开发者 慢 19% ← 方向反了
合起来的结论
初级开发者受益最大
资深开发者在通用任务上受益较小
而在他们已经很熟悉的成熟代码库里，可能反而变慢
└─ Vibe Coding 的宣传逻辑是「AI 会填平甚至反转初级与资深的差距」，
数据的方向是反的。
其他几组数据 —— 都在说同一件事：写得更多 ≠ 交付更快
Uplevel 调查 800 名开发者
客观指标（周期时间、PR 吞吐）无显著提升；用 Copilot 的一组 bug 增加 41%
Faros AI 分析 10000+ 开发者 / 1255 团队
写得更多、单任务完成更多，但交付速度与业务结果无可测改善
Stack Overflow 2025 调查
84% 在用或计划用 AI，但只有 16.3% 报告显著提效，
41.4% 说几乎没影响；正面情绪从 2023–24 的 70%+ 降到 60%其他几组数据
| 来源 | 发现 |
|---|---|
| Uplevel 调查 800 名开发者 | 客观指标（周期时间、PR 吞吐）无显著提升；用 Copilot 的一组 bug 增加 41% |
| Faros AI 分析 10000+ 开发者 / 1255 团队 | 写得更多、单任务完成更多，但交付速度与业务结果无可测改善 |
| Stack Overflow 2025 调查 | 84% 在用或计划用 AI，但只有 16.3% 报告显著提效，41.4% 说几乎没影响；正面情绪从 2023–24 的 70%+ 降到 60% |
「写得更多」和「交付更快」是两件事。 Faros 那组最能说明这一点：产出量上去了，业务指标没动。
Vibe Coding：它是怎么来的，边界在哪
出处和它的原意
Andrej Karpathy 于 2025 年 2 月 2 日在 X 上提出（那条推文 4.5M 浏览），原话：
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
一个被普遍忽略的点：Karpathy 描述的是自己做周末玩具项目时的体验，是半开玩笑的说法，不是作为通用工程实践提出的。他自己后来在 MenuGen 的复盘里也承认，代码本身还行，但周边的基建、集成与配置是一团他也不完全理解的乱麻。
几周之内，这个词被教程、YouTube、短视频吸收成了另一套更强的说法——「你不需要再理解代码了」。那个更强的说法才是站不住的。
这个词的传播量级可以参考两个数字：Collins 词典把 "vibe coding" 选为 2025 年度词汇；Y Combinator 报告 2025 冬季批次里 25% 的创业公司代码库 95% 是 AI 生成的。
分界线只有一条：读不读代码
读了再合并 = AI 辅助工程。不读 = 真正的 vibe coding。
「不读」是这个定义的核心，不是附带条件。用 AI 帮忙不构成 vibe coding，不读代码才构成。
这条线之所以是决定性的，因为**「不读」等于放弃了对未言明决定的审查权**。
根因：几百个未言明的决定
从模糊提示生成代码的 agent，必须自己做几百个决定：数据模型形状、错误处理方式、认证方案、边界情况、性能约束、安全姿态。
它每次都会做这些决定。问题只在于你是否注意到了。
具体的失效模式（过去一年在开发者社区被反复记录）：
| 失效模式 | 表现 |
|---|---|
| 认证系统 | 明文或弱哈希存密码——上线数周后在数据库审计时才被发现 |
| 数据库迁移 | 缺事务包装与回滚策略，迁移中途失败导致生产数据损坏 |
| API 端点 | 没有限流、指数退避、输入校验，上线数小时内被滥用 |
| 前端 | demo 里完美，遇到真实并发状态就崩——agent 从未被要求考虑竞态 |
| 测试套件 | 覆盖率 90%，但只测了 agent 自己想象出来的 happy path |
每一条都是资深工程师在 code review 里能拦下来的——如果有 code review 的话。
分界线只有一条：读不读代码。
用 AI 帮忙 ──┬─ 读了再合并 ──▶ AI 辅助工程
└─ 不读 ──▶ 真正的 vibe coding
└─ 「不读」是这个定义的核心，不是附带条件
为什么这条线是决定性的：「不读」等于放弃了对未言明决定的审查权。
从模糊提示生成代码的 agent，必须自己做几百个决定
├─ 数据模型形状
├─ 错误处理方式
├─ 认证方案
├─ 边界情况
├─ 性能约束
└─ 安全姿态
它每次都会做这些决定。问题只在于你是否注意到了。
具体会怎么错（过去一年被反复记录的失效模式）
认证系统 明文或弱哈希存密码 —— 上线数周后数据库审计时才发现
数据库迁移 缺事务包装与回滚策略，迁移中途失败导致生产数据损坏
API 端点 没有限流、指数退避、输入校验，上线数小时内被滥用
前端 demo 里完美，遇到真实并发状态就崩 —— agent 从未被要求考虑竞态
测试套件 覆盖率 90%，但只测了 agent 自己想象出来的 happy path
└─ 每一条都是资深工程师在 code review 里能拦下来的 —— 如果有 code review 的话三组代码质量的数据
| 来源 | 发现 |
|---|---|
| Veracode 2025（测 100+ LLM） | 45% 的 AI 生成代码样本引入 OWASP Top 10 漏洞；AI 代码的 XSS 防护失败率 86%；Java AI 代码失败率 70%+。而且这个比例从 2025 到 2026 初多轮测试都没改善 |
| CodeRabbit 2025-12（470 个开源 PR） | AI 合著代码的「major」问题多 1.7 倍，安全漏洞多 2.74 倍，配置错误多 75% |
| GitClear（纵向分析） | 重构占比从 25% 降到 10% 以下，代码重复约 4 倍，churn（写了又被快速改掉或删除）接近翻倍 |
GitClear 那组最值得琢磨：重构占比腰斩 + 重复翻倍 + churn 翻倍，说的是同一件事——代码在被生成，但很少被整理。这正是 AI 生成代码的质量保障 要处理的问题。
两个有记录的事故：
- 2025-07：一个 Replit AI agent 删除了用户的生产数据库，尽管有明确指令不要做改动
- 2025-05：1645 个用 Lovable 构建的 web 应用里，170 个被发现有泄露个人信息的漏洞
一条实用的判断规则
在看完这些数据之后，最有用的一条规则只有一个问句：
「如果这段代码坏了，谁会受伤？」
| 答案 | 做什么 |
|---|---|
| 只有我自己 | 全速 vibe。原型、一次性脚本、单用户内部工具——犯错成本是自己的时间 |
| 任何人（客户、钱、个人数据、要被别的团队继承的系统） | 逐行读。 仍然让 AI 写，但任何我解释不了的东西都不合并 |
这条规则把「Vibe Coding 好不好」这个抽象问题，换成了「这段具体代码的失败会伤到谁」这个可判断的问题。
一条判断规则，把抽象问题换成了可判断的问题。
问：如果这段代码坏了，谁会受伤？
│
├─ 只有我自己
│ └─ 全速 vibe
│ 原型、一次性脚本、单用户内部工具
│ 犯错成本是自己的时间
│
└─ 任何人（客户、钱、个人数据、
要被别的团队继承的系统）
└─ 逐行读
仍然让 AI 写，但任何我解释不了的东西都不合并
└─ 它把「Vibe Coding 好不好」换成「这段具体代码的失败会伤到谁」——
后者是可判断的
配着这条规则看三组代码质量数据
Veracode 2025（测 100+ LLM）
45% 的 AI 生成代码样本引入 OWASP Top 10 漏洞
AI 代码的 XSS 防护失败率 86%；Java AI 代码失败率 70%+
└─ 而且这个比例从 2025 到 2026 初多轮测试都没改善
CodeRabbit 2025-12（470 个开源 PR）
AI 合著代码的「major」问题多 1.7 倍，安全漏洞多 2.74 倍，配置错误多 75%
GitClear（纵向分析）
重构占比从 25% 降到 10% 以下，代码重复约 4 倍，churn 接近翻倍
└─ 三件事说的是同一件事：代码在被生成，但很少被整理工具在哪些任务上真的有用
资深工程师的实际使用模式和数据方向是一致的：
真的有收益的（「无聊的中间层」）：
- 从规格脚手架新模块或测试骨架
- 跨多文件的机械重构：重命名、签名变更、补空值处理——模式清晰但繁琐
- 从现有代码写测试用例
- 相似框架或语言之间的翻译
- 探索不熟悉的代码库、回答具体问题
这些任务是真实的加速，且模型产出「错误种类」的风险有限。它们也恰好是以前吃掉工程师一周里不成比例时间的部分。
收益小但真实的：
真正新颖的工作里，模型更多充当交互式橡皮鸭——一个用来争论架构的对象。价值真实，但难测量。
反而变慢或表现更差的:
- 在你已经很熟悉的系统里深挖隐蔽 bug——模型生成「看似合理的错修复」比生成对的更快
- 需要把大量隐式上下文装在脑子里的工作——模型不共享你的心智模型，而把足够多的上下文解释清楚，可能比自己做还费时间
- 认证、计费、数据层这类高风险代码——每一行都必须对且必须被审查
工具在哪些任务上真的有用，收益是有梯度的。
真有收益 ——「无聊的中间层」
从规格脚手架新模块或测试骨架
跨多文件的机械重构：重命名、签名变更、补空值处理
从现有代码写测试用例
相似框架或语言之间的翻译
探索不熟悉的代码库、回答具体问题
└─ 这些任务是真实的加速，且模型产出「错误种类」的风险有限
它们也恰好是以前吃掉工程师一周里不成比例时间的部分
收益小但真实
真正新颖的工作里，模型更多充当交互式橡皮鸭 —— 一个用来争论架构的对象
└─ 价值真实，但难测量
反而变慢或表现更差
在你已经很熟悉的系统里深挖隐蔽 bug
└─ 模型生成「看似合理的错修复」比生成对的更快
需要把大量隐式上下文装在脑子里的工作
└─ 模型不共享你的心智模型，而把足够多的上下文解释清楚
可能比自己做还费时间
认证、计费、数据层这类高风险代码
└─ 每一行都必须对且必须被审查Spec-Driven Development 具体是什么
它不是新概念——术语来自形式化方法与瀑布模型。2026 版的特指是：在调用 AI 编码 agent 之前，写一份结构化、可版本化的规格，让 agent 拿到明确的目标、约束与验收标准。
位置上，它在「人的意图」和「AI 的实现」之间插入一层显式规格：
人的意图
│ 模糊的提示词：「做一个记账 App」
▼
┌───────────────────────────────────────────────────┐
│ 规格（结构化、可版本化） │
│ 目标 / 约束 / 验收标准 │
│ 放在哪里：随代码一起进仓库，能 diff、能 review │
└───────────────────────────────────────────────────┘
│ 于是 agent 拿到的是明确的目标与边界
▼
AI 实现
│
▼
校验 —— 对照规格，而不是对照感觉
位置的含义：没有这一层时，上面那几百个「未言明的决定」全部由 agent 自己拍；
有了这一层，其中一部分被提到明面上，变成可以被 review 的对象。
工具链现状
GitHub Spec Kit 开源工具包，2026-05-07 时 v0.8.7，93000+ stars
AWS Kiro 整个围绕这个工作流构建的 agentic IDE
└─ 微软与 AWS 都发布过内部数据：采用 SSD 后
「从零重新生成」的循环减少 5–10 倍
一句话概括：问题始终是「无结构的 AI 辅助开发」，而不是 AI 辅助开发本身。工具链现状
| 工具 | 说明 |
|---|---|
| GitHub Spec Kit | 开源工具包，2026-05-07 时 v0.8.7，93000+ stars |
| AWS Kiro | 整个围绕这个工作流构建的 agentic IDE |
微软与 AWS 都发布过内部数据：采用 SSD 后，「从零重新生成」的循环减少 5–10 倍。
流程细节与需求侧
规格怎么写、输入输出契约怎么定、需求文档互相矛盾时怎么处理——那是 Spec 与需求理解 的内容。这一篇只定位它在整条工作流里的位置。
一句话概括
问题始终是「无结构的 AI 辅助开发」，而不是 AI 辅助开发本身。
把能力很强的工具交给聪明人，然后说「去 vibe」，不给他们任何要遵守的契约、要待在里面的护栏、要对照校验的规格——这本来就该出事。
相关
- Spec 与需求理解 —— 规格这一层的具体做法
- Harness Engineering —— 整条工作流的运行环境
- Rule 与 LLM 的边界 —— 哪些判断不该交给模型
- AI 生成代码的质量保障 —— 重构占比腰斩、重复翻倍这套数据的应对
- LLM Evaluation 与反馈闭环 —— 「感觉更快」为什么需要被测量
参考
- arXiv:2507.09089. https://metr.org
- https://aitoolradar.io/blog/vibe-coding-is-a-lie
- https://www.lampdatabase.com/posts/vibe_coding_dangers.php
- https://www.buildercog.com/blog/spec-driven-development-vs-vibe-coding-2026
- https://chercode.com/en/blog/vibe-coding-explained
- https://wcollins.io/posts/2026/from-vibes-to-specs
YJ